1. Field of the Invention
The present invention generally concerns electronic money, electronic tickets, electronic coupons, electronic checks, digital tickets and the like.
The present invention particularly concerns digital tickets that are (i) securely, quickly, inexpensively and efficiently producible, and deliverable over a worldwide digital communications network, (ii) visually inspectable, and physically securable and transportable, by the purchaser recipient thereof, (iii) resistant or immune to forgery (nonetheless that network interlopers, the purchaser recipient of an individual digital ticket and/or a number of purchaser recipients acting in collusion may attempt to so forge digital tickets), (iv) capable of being anonymously purchased, held and redeemed if so desired by the purchaser recipient thereof, (v) readily, quickly and securely verifiable upon redemption, including by laser scanning of a 2-D bar code format, or by the reading of data from a smart card, (vi) resistant to double redemption, or to single redemption after any reported theft, (vii) transferable and divisible, (viii) self-authenticating, (ix) versatile to incorporate diverse entitlements, (x) cancelable or redeemable without physical tender or surrender, and (xi) ecologically sound.
2. Description of the Prior Art
2.1 General Background
2.1.1 General Introduction
The volume of the electronic commerce, both business-to-business and business-to-consumer transactions, has dramatically increased in recent years. Most consumer Internet commerce are based on credit card transactions, and employ an ordinary package delivery service such as the U.S. Postal Service, United Parcel Service, Federal Express, or Airborne Express to send the items to the consumer. While completely reasonably for physical items such as books, music CDs, DVDs, or similar items, the use of physical delivery for the purchase of an abstraction such as access rights seems inappropriate.
What access rights are sold over the Internet? In early May, 1999, tickets to the movie Star Wars: The Phantom Menace were made available over the Internet for purchase by credit card before they were on sale at movie theater box offices. This is a particularly attractive alternative to waiting in line prior to the opening of a popular movie. Other types of access rights sold over the Internet include theater, ballet, concerts, and sporting events.
Currently, the purchase of movie tickets over the Internet requires the consumer to physically pick up the tickets, so in a sense it serves more as a reservation mechanism. For tickets to the theater or to sporting events where ticket values and prices are higher, the tickets are often delivered to the consumer by postal mail.
Tickets are physical objects that represent single-use access rights. Instead of delivery by post, the inventors of the present invention believe that such access rights should be delivered electronically in the form of digital tickets. Digital representations of the rights contained within a ticket must be verifiable at access points, e.g., by theater ticket takers, so the ticket would desirably be convertible to a physical, easily transportable form. To provide authenticity and verification, the digital ticket contents should be easily and inexpensively readable, being re-digitized from printed form if necessary, and should include an authentication tag such as a digital signature. The digital data within the digital ticket may be conveyed by the consumer to the venue of the ticket event in a variety of ways: digital data may be stored on a flexible disk, stored in a smart card, printed on paper, etc.
The inventors of the present invention will be seen to prefer the use of printed two-dimensional bar-codes as an extremely appropriate encoding technology for the purposes of digital tickets. See Stuart Itkin and Josephine Martell; A PDF417 primer: A guide to understanding second generation bar codes and portable data files; Technical Report Monograph 8, Symbol Technologies, April 1992. See also AIM Standard “Uniform Symbology Specification PDF417”. Printed 2-D bar codes provide good fault tolerance and easy re-digitization of the contained data. Digital tickets so printed permit a reasonable initial market penetration where some slight usability in the form and contents of the ticket is traded off to exploit the available consumer hardware infrastructure: namely, many web surfers have access to printers unlike the situation for smart card reader/writers.
2.1.2 Internet Ticketing Requirements
Internet tickets may be viewed as digital representations of access rights or capabilities. They may be consumed when used, or may be valid for some period of time, e.g., a movie ticket versus a series ticket for a film series. More generally, such tickets may have restrictions on their use, e.g., a movie pass good for five matinee shows.
Unlike capabilities in traditional, capabilities-oriented operating systems, the capabilities of a digital ticket are not maintained by the kernal of the operating system that transmits or reads the ticket. Perhaps the closest analogy is the Amoeba distributed kernel's use of capabilities, where capabilities are transmitted through a network. See Sape J. Mullender, editor; The Amoeba distributed operating system: Selected papers 1984–1987; Centre for Mathematics and Computer Science, 1987. In the case of Internet digital tickets, however, the generated digital tickets are ultimately carried by the consumer to the movie theater or concert venue via “sneaker-net”.
The functional requirements for Internet tickets may be considered, and compared with two other electronic commerce schemes with some very similar requirements: electronic money and digital postage. Differences in requirements, however, can make the detail designs quite different. The following sections 2.1.3 and 2.1.4 consider electronic money and digital postage indicia.
2.1.3 Electronic Money
An electronic commerce scheme that has many of the same requirements as digital tickets is electronic money. Electronic representations of money have some form of inherent value, much the same way that digital tickets do. See an excellent enumeration and explanation of the functional requirements of electronic money in T. Okamoto and K. Ohta; Universal electronic cash in Advances in Cryptology—Crypto '91, pages 324–337; Springer-Verlag, 1992.
Okamoto and Ohta list as requirements:
(1) Independence, where security of the electronic cash does not depend on some physical device.
(2) Security, where the electronic cash cannot be created except by issuing bank. Forgeries must be easy to detect. Duplicate redemption must be both detectable and traceable.
(3) Privacy, where proper usage of electronic money does not reveal consumer identity.
(4) Off-line transactability, where payment transaction does not require network access and no third party interaction is required.
(5) Transferability, where electronic money can be transferred among customers.
(6) Divisibility, where change can be made easily.
2.1.4 Information-Based Indicia, as in Electronic Stamps
Information-based indicia (IBI) provide a way to indicate on an envelope that postage has been paid. See U.S. Postal Service; Information Based Indicia Program (IBIP) New Technology Metering Devices, May 1995. The IBI standard uses a two-dimensional bar-code (PDF417) encoding a digital signature for this purpose. See U.S. Postal Service; Information Based Indicia Program (IBIP) Indicia Specification, July 1996. See also Stuart Itkin and Josephine Martell; A PDF417 primer: A guide to understanding second generation bar codes and portable data files; Technical Report Monograph 8, Symbol Technologies, April 1992.
The digital postage application is similar to that of Internet distributed digital tickets, but has requirements that force solutions to be more complex. Here, the indicia must be validated—the digital signature verified—and checked against master databases to prevent duplication, but such duplicate-spending detection may have to rely on a distributed database. Furthermore, the low value of stamps implies that for some cases, only extremely cheap fraud detection measures are cost effective. It must also be possible to print the indicium in a completely off-line manner, to limit the communications requirements at the postal centers. This leads to the use of Postal Security Devices (PSD): specialized secure co-processors which provide a secure way of maintaining account balances and performing cryptographic computations even when the PSD is in a potentially hostile environment.
Unlike indicia, tickets typically are targeted and are “spent” at some physical location indicated by the ticket itself, e.g., a movie theater, a concert hall, or sports arena. This simplifies the job of detecting duplicates, since the networking requirements are more localized than it is the case for postage indicia. At the same time, the higher value of tickets make more sophisticated fraud detection measures possible. The interactive nature of the ticket purchase transaction—which is necessary for both assigned-seating tickets and for maintaining an account of how many has been sold—permits greater flexibility in system design.
2.1.5 Internet Tickets
Many of the functional requirements for electronic money are retained for tickets. Because most tickets are consumed when used, divisibility is not a critical requirement. For the case of a pass or a concert series ticket, a simple expiration date suffices.
Tickets must be
(1) On-line deliverable: users must be able to use standard web tools such as an SSL-capable web browser to purchase and take delivery of the tickets.
(2) Secure: tickets cannot be created except by the issuing venue; forgeries are easy to detect; duplicate redemption are detectable/traceable.
(3) Private: proper usage of tickets does not necessarily reveal identity. (This is not currently a property of Ticketmaster™ or Will Call™, since identification is needed to pick up tickets.)
The on-line delivery requirement simplifies many aspects of the design. Because the ticketing venue must maintain a database of sold tickets for assigned-seating tickets, and minimally a ticket count for general admission tickets, no completely online design is admissible. While overbooking is possible—and common for some applications such as airline tickets—the number of overbookings must still be limited and controlled, since excessive overbooking is economically unsound.
2.2 Specific Background
2.2.1 Security for End-Users Accessing Web Servers
A previous technology relevant to the present invention concerns a system and product of Axent Technologies, Inc. [“Axent”] Mountain View, Calif., for tightening security for end-users accessing Web servers. The technology is so relevant because, in the first place, if a client can be securely identified to a server, and vice versa, than the server may issue the client a digital ticket.
However, a more important point of comparison is more subtle. The present invention will be seen to, at certain junctures, encrypt multiple data quantities, or fields. The fourth following paragraph will reveal that an encrypted quantity—a “message authentication code”—also becomes part of a digital ticket in the Axent system.
Axent says its “Web Defender” server software delivers proper protection in generating and distributing encrypted tickets that permit users to log into multiple Web servers across the enterprise without having to enter additional passwords each time.
Better yet, Web Defender is claimed to offer networkers a way to track and manage those tickets centrally, so that they can control access to corporate data according to individual and group names. There is no need to modify the client's browser during setup.
Web Defender sits behind the corporate firewall and works in conjunction with a Web server running a copy of Internet Information Server (IIS) from Microsoft Corporation (Redmond, Wash.). It works with both Internet Explorer from Microsoft and Communicator from Netscape Communications Corporation (Mountain View, Calif.).
In setting up Web Defender the first step is to obtain a digital certificate from a third-party certificate authority like Verisign, Incorporated (Mountain View, Calif.) for the IIS Web server. This permits the Web server to initiate an SSL (Secure Sockets Layer) session with a Web browser. Next, net managers select NT domains and groups (via a GUI) that are allowed access to the Web Defender server. Groups are selected from NT domains and then cut and pasted into Web Defender. After that it's merely a matter of selecting general ticketing properties, such as having a message sent to the Web browser once the sign-on process is successful or automatically reissuing a ticket once the old one expires.
So how does the Web Defender software “pump up” security? First, a user keys in a name and password, which are authenticated by the Web Defender server. (It's important to note that passwords and user names are exchanged only once during this initial authentication, over the SSL connection). Second, the Web Defender server builds a user ticket that contains several fields of data, such as user name, lifespan of ticket, and group name; all of which define the data the ticket holder can access. Third, the ticket is run through the MD5 cryptographic algorithm developed by RSA Data Security Incorporated (Redwood City, Calif.) to generate a message authentication code, which becomes part of the ticket itself. At this point, the digital ticket is issued and stored in the memory of the user's Web browser. Once the session is completed, the ticket is deleted from the memory.
2.2.2 Previous Patents
A series of patents to Stefik, et al. and assigned to Xerox Corporation (Stamford, Conn.) deal with the distribution and use of digital works of value, including (but not limited to) digital tickets. U.S. Pat. No. 5,715,403 is for a SYSTEM FOR CONTROLLING THE DISTRIBUTION AND USE OF DIGITAL WORKS HAVING ATTACHED USAGE RIGHTS WHERE THE USAGE RIGHTS ARE DEFINED BY A USAGE RIGHTS GRAMMAR; U.S. Pat. No. 5,638,443 is for a SYSTEM FOR CONTROLLING THE DISTRIBUTION AND USE OF COMPOSITE DIGITAL WORKS; U.S. Pat. No. 5,634,012 is for a SYSTEM FOR CONTROLLING THE DISTRIBUTION AND USE OF DIGITAL WORKS HAVING A FEE REPORTING MECHANISM; and U.S. Pat. No. 5,629,980 is for a SYSTEM FOR CONTROLLING THE DISTRIBUTION AND USE OF DIGITAL WORKS. The earliest incorporated application Ser. No. 08/344,760, entitled “SYSTEM FOR CONTROLLING THE DISTRIBUTION AND USE OF DIGITAL WORKS USING DIGITAL TICKETS” did not issue as a patent.
These patents are of relevance to the present invention primarily as background, especially as regards the nature of security of a system communicating on and over a network. The use of “trusted repositories” in the patents is without direct counterpart in the basic system of the present invention. However, it will be recognized that a the present invention is susceptible of universal adaptation and deployment for use in issuing billions of tickets monthly, and not all tickets—even for the same event—will come from the same issuing authority. The Xerox patents thus show how the digital ticket issuing system and method of the present invention can be indefinitely expanded.
All these patents concern a system for controlling use and distribution of digital works. The system permits the owner of a digital work to attach usage rights to his or her work. The usage rights define how the individual digital work may be used and distributed. Instances of usage rights are defined using a flexible and extensible usage rights grammar. Conceptually, a right in the usage rights grammar is a label associated with a predetermined behavior and conditions to exercising the right. The behavior of a usage right is embodied in a predetermined set of usage transactions steps. The usage transaction steps further check all conditions which must be satisfied before the right may be exercised. These usage transaction steps define a protocol for requesting the exercise of a right and the carrying out of a right.
The patents thus relate to the field of distribution and usage rights enforcement for digitally encoded works. The deal with the fundamental issue facing the publishing and information industries in preventing the unauthorized and unaccounted distribution or usage of electronically published materials. Electronically published materials include diverse types typically distributed in a digital form and recreated on a computer based system having the capability to recreate the materials. Although the patents focus on audio and video recordings, software, books and multimedia works as exemplars of electronic publishing, digital tickets may also be considered to be electronically published works and, indeed, ones of at least transitory value.
The Xerox patents address the problem of the secure distribution of digital works by use of trusted repositories. Many of the powerful functions of repositories—such as their ability to “loan” digital works or automatically handle the commercial reuse of digital works—are possible because they are trusted systems. The systems are trusted because they are able to take responsibility for fairly and reliably carrying out the commercial transactions. That the systems can be responsible (“able to respond”) is fundamentally an issue of integrity. The integrity of repositories has three parts: physical integrity, communications integrity, and behavioral integrity.
Physical integrity refers to the integrity of the physical devices themselves. Physical integrity applies both to the repositories and to the protected digital works. Thus, the higher security classes of repositories themselves may have sensors that detect when tampering is attempted on their secure cases. In addition to protection of the repository itself, the repository design protects access to the content of digital works. In contrast with the design of conventional magnetic and optical devices—such as floppy disks, CD-ROMs, and videotapes—repositories never allow non-trusted systems to access the works directly. A maker of generic computer systems cannot guarantee that their platform will not be used to make unauthorized copies. The manufacturer provides generic capabilities for reading and writing information, and the general nature of the functionality of the general computing device depends on it. Thus, a copy program can copy arbitrary data. This copying issue is not limited to general purpose computers. It also arises for the unauthorized duplication of entertainment “software” such as video and audio recordings by magnetic recorders. Again, the functionality of the recorders depends on their ability to copy and they have no means to check whether a copy is authorized. In contrast, repositories prevent access to the raw data by general devices and can test explicit rights and conditions before copying or otherwise granting access. Information is only accessed by protocol between trusted repositories.
Communications integrity refers to the integrity of the communications channels between repositories. Roughly speaking, communications integrity means that repositories cannot be easily fooled by “telling them lies.” Integrity in this case refers to the property that repositories will only communicate with other devices that are able to present proof that they are certified repositories, and furthermore, that the repositories monitor the communications to detect “impostors” and malicious or accidental interference. Thus the security measures involving encryption, exchange of digital certificates, and nuances described below are all security measures aimed at reliable communication in a world known to contain active adversaries.
Behavioral integrity refers to the integrity in what repositories do. What repositories do is determined by the software that they execute. The integrity of the software is generally assured only by knowledge of its source. Restated, a user will trust software purchased at a reputable computer store but not trust software obtained off a random (insecure) server on a network. Behavioral integrity is maintained by requiring that repository software be certified and be distributed with proof of such certification, i.e. a digital certificate. The purpose of the certificate is to authenticate that the software has been tested by an authorized organization, which attests that the software does what it is supposed to do and that it does not compromise the behavioral integrity of a repository. If the digital certificate cannot be found in the digital work or the master repository which generated the certificate is not known to the repository receiving the software, then the software cannot be installed.
All repositories provide a core set of services for the transmission of digital works. The manner in which digital works are exchanged is the basis for all transaction between repositories. The various repository types differ in the ultimate functions that they perform. Repositories may be devices themselves, or they may be incorporated into other systems.
A repository will have associated with it a repository identifier. Typically, the repository identifier would be a unique number assigned to the repository at the time of manufacture. Each repository will also be classified as being in a particular security class. Certain communications and transactions may be conditioned on a repository being in a particular security class.
As a prerequisite to operation, a repository will require possession of an identification certificate. Identification certificates are encrypted to prevent forgery and are issued by a Master repository. A master repository plays the role of an authorization agent to enable repositories to receive digital works. Identification certificates must be updated on a periodic basis. Identification certificates are described in greater detail below with respect to the registration transaction.
A repository has both a hardware and functional embodiment. The functional embodiment is typically software executing on the hardware embodiment. Alternatively, the functional embodiment may be embedded in the hardware embodiment such as an Application Specific Integrated Circuit (ASIC) chip.
The hardware embodiment of a repository will be enclosed in a secure housing which if compromised, may cause the repository to be disabled. The basic components of the hardware embodiment of a repository include a processing means, a storage system, a clock and an external interface.
The core repository services comprise a set of functions required by each and every repository. The core repository services include the session initiation transactions. This set of services also includes a generic ticket agent which is used to “punch” a digital ticket and a generic authorization server for processing authorization specifications. Digital tickets and authorizations are specific mechanisms for controlling the distribution and use of digital works. Note that coupled to the core repository services are a plurality of identification certificates. The identification certificates are required to enable the use of the repository.
For one-time usage rights, a variant on this scheme is to have a digital ticket. A ticket is presented to a digital ticket agent, whose type is specified on the ticket. In the simplest case, a certified generic ticket agent, available on all repositories, is available to “punch” the ticket. In other cases, the ticket may contain addressing information for locating a “special” ticket agent. Once a ticket has been punched, it cannot be used again for the same kind of transaction (unless it is un-punched or refreshed in the manner described below.) Punching includes marking the ticket with a timestamp of the date and time it was used. Tickets are digital works and can be copied or transferred between repositories according to their usage rights.
In the currently preferred embodiment, a “punched” ticket becomes “un-punched” or “refreshed” when it is copied or extracted. The Copy and Extract operations save the date and time as a property of the digital ticket. When a ticket agent is given a ticket, it can simply check whether the digital copy was made after the last time that it was punched. Of course, the digital ticket must have the copy or extract usage rights attached thereto.
The capability to un-punch a ticket is important in the following cases:
(1) A digital work is circulated at low cost with a limitation that it can be used only once.
(2) A digital work is circulated with a ticket that can be used once to give discounts on purchases of other works.
(3) A digital work is circulated with a ticket (included in the purchase price and possibly embedded in the work) that can be used for a future upgrade.
In each of these cases, if a paid copy is made of the digital work (including the ticket) the new owner would expect to get a fresh (un-punched) ticket, whether the copy seller has used the work or not. In contrast, loaning a work or simply transferring it to another repository should not revitalize the ticket.
2.2.3 Framework for a General-Purpose Digital Ticket
Ko Fujimura and Yoshiaki Nakajima of NTT Information and Communication Systems Labs are active in digital tickets. Mr. Fujimura conceives of a flexible digital ticket whose main purpose is to develop a generic value-circulation medium that prevents double-spending. In this context, a ticket is a digital medium that guarantees certain rights to the owner of the ticket. Describing tickets this generally allows the tickets to contain many different values and types of values in a single ticket (or group thereof).
Mr. Fujimura claims that a general ticket framework will reduce the implementation cost in many cases because a single design can be used in many places. By being general, the tickets can be composed arbitrarily, allowing bundling and similar features. He claims that the creation of new businesses to run this framework, like issuing/revocation services and deposit box services, was a benefit.
A general-purpose digital ticket framework must meet most of the requirements of digital cash. Additional requirements are: (1) A ticket can control its anonymity, divisibility, and transferability depending on the application; (2) The individual specifications of a ticket need to be “machine understandable” to allow for the redemption of goods or services; (3) Ticket properties whose values change while it is circulated (e.g., payment or reservation status) must be changed securely; (4) A ticket that comprises more than one sub-tickets must be supported.
To implement such a framework, the authors created a Ticket Definition Language that allows for the specification of ticket properties. The tickets themselves are hypertext-based, allowing automation of the state-transitions and composability features. The tickets can also include dynamic information that is up-to-date when the ticket itself is used. Another feature (of less obvious utility) is that the tickets can contain very large data such as images and sounds.
The tickets themselves are inherently online (because of their hypertext basis and dynamic nature), but can also be circulated offline using smart cards. In either case, the system uses signed URIs to test the currency of the ticket. The meaning and constraints of the properties in the tickets are defined using the Resource Description Framework. Schemas for tickets can thus be controlled by the issuers of the tickets, and various restrictions can be contained in these schemas.
Fujimura outlined the ticket trust model. The issuer certificate, user certificate, and examiner certificate, which are required to issue, transfer, consume, or examine a ticket, are specified in the ticket itself using the Ticket Definition Language. So, any ticket with a public key, such as drivers' licenses, can be used as a public key certificate if a ticket specifies them as a required certificate for the ticket. In other words, any ticket can play a roll in the public key infrastructure for other tickets.
Fujimura and Nakajima are drafting specifications for the implementation and intend to submit them to standards organizations. The goal of their project is to “Transform any Web terminal into a ticketing machine for any ticket in the world.” The present invention has the same goal.
2.2.4 XML Ticket: Generalized Digital Ticket Definition Language
There is an effort, spearheaded by Nippon Telephone and Telegraph (NTT) to formulate a generalized digital ticket definition language called “XML Ticket”. This definition language, and this prototype standard, are in no way in conflict with the present invention. The standard concerns what a digital ticket of general format should contain; the present invention concerns how to securely generate and redeem a digital ticket.
Ko Fujimura, Yoshiaki Nakajima, and Jun Sekine of NTT Information Sharing Platform Laboratories write that the World Wide Web provides an information delivery infrastructure for various types of digital contents used in daily life. Payment infrastructures such as digital cash, micropayments, and encrypted credit cards have also been established. However, no digital medium or infrastructure that prevents duplicate redemption and enables the trading of various rights, much like paper tickets, has been established yet.
Messrs. Fujimura, Nakajima and Sekine have thus sought to develop a generalized digital ticket system that can circulate any type of rights. A digital ticket is a digital medium that guarantees certain rights of the ticket owner and it includes software licenses, resource access tickets, event tickets, plane tickets, etc. To circulate various types of digital tickets using a common ticket processing system, they propose a general-purpose digital ticket framework, in which a ticket is circulated by interpreting ticket properties such as anonymity, transferability, and the redemption method, specified in the ticket itself using the XML based Generalized Ticket Definition Language.
Traditional digital ticket systems were developed for each application. However, Messrs. Fujimura, Nakajima and Sekine believe that a generalized digital ticket system is necessary for the following reasons:
(1) A ticket processing system includes a ticketing system, ticket wallet, ticket examination system, and the implementation cost of these components becomes expensive if a system must be developed for each individual application. For example, it is impractical to develop an individual system for an application that issues only 20 tickets.
(2) It is desirable for users to manage various tickets using a common “ticket wallet” that provides a uniform and collected view as a real physical wallet, in which cash, credit cards, ID cards, and various tickets are stored together.
(3) New network businesses such as revocation, packaging, and safety deposit box services can be run if any ticket can be managed uniformly. If the format and protocols for digital ticket circulation depend on the ticket, it would be difficult to run these businesses successfully.
As a result of their investigation on diverse physical tickets, Messrs. Fujimura, Nakajima and Sekine have identified the following requirements for the generalized digital ticket definition language:
(1) Composability: The language must support a composite ticket that comprises multiple sub-tickets. There are many cases when a sub-ticket must be issued separately with the original ticket typically because the tickets are issued by different organizations or issued at different times.
(2) State manageability: The language must support the defining of properties whose values dynamically change while in circulation, e.g., payment, reservation, or approval status. Note that it is difficult to allow these changes in a signed document.
(3) Machine-understandability: The language must support the defining of the meaning of the ticket. If the service or task that a ticket guarantees is objectively understood by the buyer and seller before conducting a transaction, it will reduce the number of disputes resulting from misunderstanding of the meaning of the ticket.
(4) Efficiency: The language must enable the efficient defining of a ticket, since it might be stored in a smart card or other devices with restricted memory. Longer definitions also cause longer data transfer time, which might not be acceptable. For example, redemption of event tickets or transportation passes requires high performance.
(5) Circulation controllability: The language must provide the parameters needed to allow flexible circulation control. As shown in Table I, the anonymity, transferability, and redemption method of the ticket must be specified in the ticket definition. Additionally, it is desirable to support more advanced requirements, e.g., tickets can be circulated within the registered members of a group or only qualified shops can issue tickets.
(6) Security: The investigators perceive that the language must provide the parameters needed to achieve security. (The present invention teaches that the method, and contents of the ticket—not the language in which its contents are represented—is what provides the security.) The digital ticket system must support a facility for preventing duplicate redemption similar to a digital cash system. It requires an online currency checking system or tamper-proof devices such as a smart card as well as digital signature technologies.
The investigators adopted extended markup language, or XML, as the base language of the Generalized Digital Ticket Definition Language, since they allege to satisfy the above requirements as described below:
(1) Composability: A composite ticket is claimed to be definable using XML links. A composite ticket in which sub-tickets are distributed over the Internet is claimed to be easily implementable. It is claimed that this facility is useful especially for tickets that are often revoked and when online checking is required.
(2) State manageability: The state-transition properties of a ticket is claimed to be uniformly defined by attaching a value change ticket to the restriction-specified incomplete link.
(3) Machine-understandability: The meaning of a ticket is defined using the Resource Description Framework (RDF) Model; the Syntax Specification (see http://www.w3.org/TR/REC-rdf-syntax); and and the Resource Description Framework (RDF) schemas (see http://www.w3.org/TR/REC-rdf-schema), which are layered on XML. It is claimed that this will make searching for tickets over the Internet much easier.
(4) Efficiency: By circulating the link to contents such as ticket images or contract details instead of defining the contents on the tickets themselves, it is claimed that the size of the ticket can be reduced. The link is also asserted to provide up-to-date information over the Internet. For example, an event ticket may include a link to the place where the event will be held after it was postponed due to rain or something else.
(5) Circulation controllability & Security: XML is a generic language designed to describe any structured data and thus any parameters necessary to control ticket circulation can be defined. Establishing control parameters or security parameters, which are necessary to satisfy these requirements, do not significantly influence the language as a ticket processing system.
Reference R. D. Brown, “Digital Signatures for XML”, IETF Internet Draft, January 1999; K. Fujimura and Y. Nakajima, “General-purpose Digital Ticket Framework”, 3rd USENIX Workshop on Electronic Commerce, August 1998, pp. 177–186. (See http://www.usenix.org/publications/library/proceedings/ec98/fujim ura.html.) Reference also K. Fujimura, Hiroshi Kuno, Masayuki Terada, Kazuo Matsuyama, Yasunao Mizuno and J. Sekine, “Digital Ticket Controlled Digital Ticket Circulation”, to appear; and Y. Nakajima and K. Fujimura, “The XML Ticket Specification”, unpublished manuscripts. Reference also XML Schema Requirements, The World Wide Web Consortium, Note, February 1999. (See http://www.w3.org/TR/NOTE-xml-schema-req).
The relevance of all this work to the present invention is: it all applies. The present invention concerns the manner of securely generating, distributing and redeeming a digital ticket, and has no quarrel, and, indeed, some agreement, that the information within the ticket (and still other information, such as patterns of ticket circulation, or geographical sites that are enabled to purchase tickets) should be expressed in an advanced language such as XML.
2.3 Digital Signatures
The present invention will be seen to employ a digital signature—a routine concept in the cryptographic arts. The present invention is fully operative with many different schemes of producing digital signatures.
For example, in the Rivest Shamir Aldeman (RSA) public key encryption system, a party has both a public key (N,e) and a secret key (N,d), where N is a k-bit modulus, the product of two (k/2)-bit prime numbers, and e, dεZφ(N)* satisfy ed≡1 mod φ(N). The RSA function f: ZN*→ZN* is defined by f(x)=xe mod N and its inverse x−1: ZN*→ZN* is defined by f−1(y)=yd mod N (x, yεZN*), where ZN* denotes the set of numbers between 1 and N−1 which are relatively prime to N). The function f can be used for encryption, and the function f−1 for decryption. The generally-made assumption is that f is trapdoor one-way: roughly, if one does not know d (or he prime factors of N) then it is hard to compute x=f1(y) for y drawn randomly from ZN*.
A widely employed paradigm to sign a document M is to first compute some “hash” y=Hash(M), and then set the signature to x=f−1(y)=yd mod N. To verify that x is a signature of M, one computes f(x)=xe mod N and checks that this equals Hash (M). This technique is the basis for several existing standards.